Distributed process control systems, like those used in chemical, petroleum or other process plants, typically include one or more process controllers communicatively coupled to one or more field devices via I/O cards or devices, analog, digital or combined analog/digital buses, and/or a wireless communication link or network. The field devices, which may be, for example, valves, valve positioners, actuators, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and generally perform physical or process control functions such as opening or closing valves, measuring process parameters such as pressure, temperature, etc., and the like to control one or more process executing within the process plant or system. Smart field devices, such as the field devices conforming to the well-known Fieldbus protocol, may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, e.g., via a respective I/O card or device, and execute a controller application that runs, for example, different control modules which make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being performed in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines or links to the field devices to thereby control the operation of at least a portion of the process plant or system. As utilized herein, field devices, I/O cards or devices, and controllers are generally referred to as “process devices” or “process control devices.”
Information from the field devices and the controller is usually made available over a data highway to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized administrative computing devices that are typically placed in control rooms or other locations away from the harsher plant environment. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices run applications that may, for example, enable an operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routine, modifying the operation of the control modules within the controllers or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers and field devices may include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths.
As an example, the DeltaV™ control system, sold by Emerson Process Management, includes multiple applications stored within and executed by different devices located at diverse places within a process plant. A configuration application, which resides in one or more workstations or computing devices, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which are objects in an object oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality. The viewing applications, which may be executed on one or more operator workstations (or on one or more remote computing devices in communicative connection with the operator workstations and the data highway), receive data from the controller application via the data highway and display this data to process control system designers, operators, or users using the user interfaces, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may run in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
Generally speaking, a process control system of a process plant includes field devices, controllers, workstations, and other devices that are interconnected by a set of layered networks and buses. The process control system may, be in turn, be connected with various business and external networks, e.g., to reduce manufacturing and operational costs, enhance productivity and efficiencies, provide timely access to process control and/or process plant information, etc. On the other hand, the interconnection of process plants and/or process control systems to enterprise and/or external networks and systems increases the risk of cyber intrusions and/or malicious cyber-attacks that may arise from expected vulnerabilities in commercial systems and applications, such as those used in enterprise and/or external networks. Cyber intrusions and malicious cyber-attacks of process plants, networks, and/or control systems may negatively affect the confidentiality, integrity, and/or availability of information assets, which, generally speaking, are vulnerabilities similar to those of general purpose computing networks. However, unlike general purpose computer networks, cyber intrusions of process plants, networks, and/or control systems may also lead to damage, destruction, and/or loss of not only plant equipment, product, and other physical assets, but also to the loss of human life. For example, a cyber intrusion may cause a process to become uncontrolled, and thereby produce explosions, fires, floods, exposure to hazardous materials, etc. Thus, securing communications related to process control plants and systems is of paramount importance.
FIG. 1 includes a block diagram 10 of example levels of security for a process control or industrial process system. The diagram 10 depicts interconnections between various components of the process control system, the process control system itself, and other systems and/or networks to which the process control system may communicatively connect, as well as layers or levels of security relating to communications in and between the process control system and the other systems/networks. The security levels provide a layered approach to security via segmentation or separation, and various levels are protected by one or more firewalls 12a, 12b, 12c to allow only authorized traffic between the different levels. In FIG. 1, the lower-numbered security levels are closer to the on-line process that is being controlled, while the higher-numbered security levels are more removed from the executing process. Accordingly, trust levels (e.g., a relative degree of trust that messages, packets, and other communications are safe) are the highest at the device level (Level 0), and trust levels are the lowest above the business network level (Level 5), e.g., on the public Internet. Using the Purdue Model for Control Hierarchy logical framework standardized by ISA (International Society of Automation) 95.01-IEC (International Electrotechnical Commission) 62264-1, process control systems generally fall into Levels 0-2, and manufacturing, corporate, and enterprise systems generally fall into Levels 3-5.
Examples of different functionalities at each of the different security levels are shown in FIG. 1. Typically, Level 0 includes field devices that have direct contact with the process, for example, sensors, valves, valve positioners, switches, transmitters, and other devices that perform physical and/or process control functions such as opening or closing valves, measuring process parameters such as pressure, temperature, etc., and the like. For clarity of illustration, example field devices are not shown in FIG. 1.
Level 1 includes controllers and other process control devices 15a-15d that provide basic control of real-time operations of the process, e.g., by receiving input from field devices, processing the input using control schemes, modules, or logic, and sending resultant output to other devices. For example, process control devices at Level 1 may include process controllers, programmable logic controllers (PLCs), Remote Terminal Units (RTUs), and the like. Generally, such process control devices are programmed and/or configured with respective control schemes. As shown in FIG. 1, the process control devices at Level 1 may include those that perform batch control 15a, discrete control 15b, continuous control 15c, hybrid control 15d, and/or other types of control.
Level 2 includes devices and equipment 18A-18D that provide production area supervisory control. For example, Level 2 may include alarming and/or alerting systems 18A, operator workstations 18C, other Human Machine Interfaces (HMIs) 18B, 18D, and the like. Generally, Level 2 devices and equipment may communicate with Level 1 devices 15A-15D, as well as with Level 3 devices and equipment, e.g., via one or more firewalls 12A, 12B.
Level 3 houses plant systems and/or networks, e.g., the devices, equipment, and systems 20A-20D that manage site/plant operations and control to produce or manufacture a desired end product. For example, Level 3 may include production systems 20A that are used for production control, reporting, scheduling, etc.; optimization systems 20B that are used for improving quality, productivity, efficiencies, etc.; historians 20C for historizing data generated by and/or indicative of the process plant; and/or engineering workstations or computing devices 20D used by personnel for design and development of control schemes and modules, operator workstation and/or HMI interfaces, etc.
Skipping to Level 5, Level 5 generally houses business, corporate, or enterprise systems and/or networks. Typically, such systems and/or networks manage the interfacing with systems outside of the enterprise. For example, an enterprise's VPN (Virtual Private Network), corporate or enterprise Internet access services, and/or other IT (Information Technology) infrastructure systems and applications may be found in Level 5.
Level 4, which may be viewed as an inward extension of Level 5, generally houses corporate or enterprise systems that are internal to the enterprise, such as email, intranet, site business planning and logistics, inventory, scheduling, and/or other corporate/enterprise systems and networks.
As shown in FIG. 1, Level 3 and Level 4 are separated by a demilitarized zone (DMZ) 22 to separate business or enterprise systems and/or networks from plant/process systems and/or networks, thereby minimizing the level of security risk to which a process plant is exposed. The DMZ 22 may include one or more respective firewalls 12C, and may house various devices, equipment, servers, and/or applications 25A-25F that communicate with plant-related devices, equipment, and applications at lower levels, and/or with enterprise-related devices, equipment, and applications at higher levels. For example, the DMZ 22 may house Terminal Services 25A, Patch Management 25B, one or more AV Servers 25C, one or more Historians 25d (which may be mirror historians), Web Services Operations 25E, and/or one or more Application Servers 25F, to name a few. Typically, for devices, equipment, and/or applications at levels above the DMZ 22, only those that are authorized to access the process plant and its control systems are required to connect to the devices, equipment, servers, and/or applications 25A-25F which, in turn, maintain separate connections to the lower levels, thereby protecting the process plant and control system from attacks from the enterprise (and higher) systems and/or networks.
Turning now to a brief discussion of remote services, remote services are becoming more and more commonly used by different users and systems. For example, the Remote Desktop Services product provided by the Microsoft Windows® operating system enables users to access session-based desktops, virtual machine-based desktops, or and/or other applications in a data center from a corporate network and/or from the Internet. The QuickBooks® Online product provided by Intuit® enables users to perform accounting functions such as cash flow management, issuing invoices, and making payments online via the Internet. Generally speaking, remote services are provided by one or more applications that execute remotely from the system or user that accesses the remote service. For example, the one or more applications execute and manage data at a remote bank of servers, in the cloud, etc., and are accessed via one or more private and/or public networks, such as an enterprise network and/or the public Internet.